BCI NET

home *** CD-ROM | disk | FTP | other *** search

/ BCI NET / BCI NET Dec 94.iso / archives / programming / source / gadlay17.lha / Style_Guide < prev next >

Wrap

Text File | 1993-03-30 | 18.5 KB | 366 lines

Judging a Book by its Cover: A Synopsis of the "Amiga User Interface Style Guide" Copyright (c) 1993 by Timothy J. Aston All Rights Reserved Editor: Mark Rickan * Introduction: If you've ever used such graphic operating systems as the Macintosh, Windows on a PC-clone, or a NeXT, you've likely come to appreciate the consistency in the way their applications both appear and operate. Through the enforcement of strict interface guidelines and the increasing competition among vendors, developers have become particularly concerned with how their software conveys a sense of professionalism and attention to detail. The important factor here is "consistency" in the look and functionality of different applications running under the same operating system. Apple, Microsoft, NeXT and others created a set of guidelines to ensure that developers would provide applications that would look and act alike on their particular systems. Functions common to most applications, such as selecting a file, would then be performed in an identical fashion in all applications. In the formative years of the Amiga, many applications could be described as in a state of chaos when it came to user interface design. With no real established standards and a limited set of resources for product development, many programmers inevitably developed software on the basis of their own impressions of how a software package should look and feel. Anyone that has either owned or used an Amiga since the days of Release 1.3 of the operating system won't need to be reminded that Release 2 was a major revolution to the Amiga as a whole. This revision of the operating system and its graphic user interface (+) -- or GUI, pronounced "gooey" -- forever changed the way users would interact with the the Amiga. With an impressive new 3-dimensional look, 2.0 heralded the beginning of a new era. Today, programmers have can access a variety of functions in the operating system to create attractive and powerful user interfaces for their software. In addition, Commodore has provided a set of guidelines for software development which are embodied in the "Amiga User Interface Style Guide". This book brought to the Amiga an element which had traditionally been absent: user interface standards. The text covers a broad spectrum of user interface issues such as pull-down menu layout, requester design, ARexx command interfaces and keyboard equivalents. Developers now have official guidelines they need to ensure that their applications will be consistent, powerful and easy to use. (+) Although the term coined by MicroSoft is in fact "graphical user interface", I have used the word "graphic" instead, as there is no such word in the English language as "graphical". * The Problem: Sadly, this major advancement for the Amiga has turned into somewhat of a disappointment. What could have led to a major step forward in the overall quality of Amiga software has not yet been realized to its full potential. Though the Style Guide has been available for almost two years now, there have been almost no commercial, and only a few shareware or public domain software packages that follow its guidelines. Why is this so? If the comments in the introduction are indeed true, why haven't the guidelines laid out in the Style Guide been heartily embraced by developers? The reason appears to be two-fold: 1) Lack of knowledge: A large number of people, particularly users, are not aware of the Style Guide, nor have they come to appreciate how important standards are. 2) Insistence on creative freedom: Among many developers, there is a tendency to create software which looks and acts according to personal preferences. This is also coupled with concerns to continue supporting the now obsolete Release 1.3 revision of the Amiga's OS. Because the Style Guide assumes Release 2, it is difficult to write Style Guide compliant software that still runs on older versions of the OS. One of the goals of this document is to help address the first reason. By learning that standards exist, it is hoped that users will increasingly appreciate the need for programs that follow these standards. In the following section, a brief overview of some of these standards will be provided to give users some idea of what constitutes a standard interface. * The Guidelines: Some people seem to be of the opinion that as long as their programmes conform to the 3-D look of Release 2, that their software may be considered as having a "standard user interface". This could not be farther from the truth. The Style Guide contains a very extensive list of guidelines, all of which should be followed as closely as possible in order to earn the distinction of being style-guide compliant. I will now take some time to provide a brief synopsis of some of these guidelines. This overview will give users a basic understanding of how an Amiga application should act. It may also be helpful as an introduction for developers. Please keep in mind however, that it is essential to obtain a copy of the Style Guide before you release any software in order to make certain that you are fully compliant. - The Basename: Every program should have a basename. This is a simple string that identifies the program. For the most part, this can simply be the name of your programmes binary. If the program has a fairly long name, it should be abbreviated to something more manageable. But be careful, if you abbreviate too much, your basename will become ambiguous and fail to properly identify your program. - Pull-Down Menus: Most applications share a set of basic functions. For example, just about every program has to allow the user to load and save a file. Most programmes also need to let users change program options. Other common functions include items such as support for the clipboard and macros and other features. These functions should be laid out in the pull-down menus in a very specific manner, using specific names. Additionally, pull-down menus should use the same font as the screen they are on, and should be drawn in the pen colours given to you by the OS. (This is accomplished by using functions in the GadTools library). Briefly, here is how the Style Guide states the menus should appear. Of course, not all programmes will implement all of these items, since they are not appropriate for all applications. Project Edit Macros Settings New N Cut X Start Learning / Option Open... O Copy C Stop Learning / Option <bar> Paste V Assign Macro... / Create Icons? Save S <bar> Load... <bar> Save As... A Erase Z Save.. Option... <bar> <bar> Option >> Print Undo <bar> Print As.. Redo Load Settings... <bar> Save Settings Hide Save Settings As... Reveal... Close <bar> About... <bar> Exit Level <bar> Quit Program... Q A few notes on the above: First, the capital letters following some items denote Amiga key equivalents, the "/" refers to an item that may be "checked", ">>" means that the item brings up a submenu, and <bar> represents the standard bar separator item. Stylistic points you should note include the use of the elliptics ("...") for items that will bring up some kind of requester in response to their selection. In the "Settings", note how toggle items come first, followed by items that bring up a requester, followed by items that bring up sub-menus. Note also the placement of the bars. This menu should be the last menu unless you have implemented the "User" menu described following. A menu called "User" may be provided for user defined macros. This menu will be variable length and could hold anything the user wishes to configure for it. This should be the last menu, pushing the "Settings" to the second to last position. - Preferences Files: As mentioned above, any program that allows users to adjust its settings in any way should have a "Settings" menu from which users can do this. For the most part, you will also want to be able to load and save these settings. If a program has only a very small amount of things that it has to save as a part of the settings (eg. half a dozen or less variables), then a convenient way is to save them as "tool types" in the program's icon file (the .info file). In most cases, you'll have a fair number of settings options, thus you'll need to keep them in a seperate file. The way you decide which file to use is by following these steps according to sequence: 1. Check for a user supplied settings filename, via either the SETTINGS workbench tool type or command line keyword. 2. Look in the current directory for a file called <basename>.prefs. 3. Look in the directory in which the program resides in (programmers: use the special AmigaDOS assignment PROGDIR: to facilitate this) for <basename>.prefs. 4: Look in ENV:<basename>/<basename>.prefs. The Style Guide suggests using the IFF format for your settings files. - Keyboard controls: It is important for software to have facilities for effective keyboard and mouse control. Try to make it so that you can do as much as possible with both the keyboard and the mouse, but don't go to extremes simply for the purpose of providing complete keyboard control. For example, if you try to give every gadget in a requester a keyboard equivalent, you'll probably end up having keys that have little relation the gadget text. Keyboard equivalents in menus are simple to implement, as the OS does just about all the work for you. Just remember to follow the equivalents suggested by the Style Guide. Gadgets require a little more work in order to give them keyboard equivalents. The operating system will handle the placement of an underscore under the character that will serve as an equivalent to gadget selection. But remember, you have to check for the keypresses yourself. These keypresses should be accepted unqualified, accept in the case of cycle and listview gadgets, where the unqualified key should give you the next item in the gadget and a shifted entry selects the previous item. The cursor keys should be used to move around within your project. Unqualified, they should move you up, down, left or right one "unit" (eg. a character in a word processor). <shift> plus a cursor key should move you to the appropriate extreme within the current view of the window, and if already there, move you along the size of the view. <control> plus a cursor should move you to the appropriate extreme of the project. <alt> along with a cursor is not defined, its usage is left up to the application. - ARexx: As with menus, we see a lot of programs that have ARexx commands on different applications that are similar in function, but have different names. The Style Guide attempts to remedy this somewhat by providing a set of standard commands. Naturally, the scope of commands an application might support will go far beyond what can be detailed in any document, but a program should support as many of the Style Guide commands as possible. The ARexx port name of an application has a naming convention: <basename>.<instance> where <instance> is the execution instance of the program in case it has been run multiple times at once by the user. It can also be a project number in the event that the program lets you work on several projects at once. Even simple program should try to support as many ARexx commands as possible, even if this amounts to as few as half a dozen commands. * The Style Guide in Practice: Naturally, it is going to be difficult for programmers to have their applications follow the Style Guide word for word. Some things will have to be left out if not supported by the application, and when it comes to adding things not discussed in the Style Guide, you're on your own. There are also going to be cases where the Style Guide specifications simply will not make provisions for enough power, and functions will have to be implemented differently. All you have to do is be a little mindful when implementing the Style Guide. Try to follow it as closely as you can. When it comes to adding things that are beyond what is in the Style Guide, look at what else is out there to see if there are some common practises. A fine example of this is the folder gadget for bringing up a file requester to select a directory. This was something we originally saw in Commodore's Fountain, and has since appeared in other software such as ToolManager and Term It is not something that is talked about in the Style Guide, but it is a common practise, and from the point of view of the user, that's almost the same thing as a standard. There are also a few cases where your opinion may differ from the official guidelines. One example is with cursor movements. The Style Guide says that <control> + <up cursor> or <down cursor> should move you to the upper or lower extreme respectively. What we see most commonly however is <alt> being used instead of <control>. I find the best idea is to use both, since the function for <alt> can be program specific. There also appears to be at least one case where you can make a very substantial argument against a Style Guide suggestion. This one case that I am familiar with is with the SELECT ARexx command. This seems to be a poor choice in name, since SELECT is a built-in ARexx command, and to actually send this command to an application via ARexx requires extra care. My suggestion is to implement this command, but to also add a command called REVEAL as a synonym. I would also like to point out that the Style Guide really only sets up guidelines for a MINIMAL user interface. You should comply with its guidelines, but to have an interface that goes beyond merely adequate, you'll have to do more. The few Style Guide compliant GUIs I have seen have been quite dull indeed. Don't be afraid to use images in your gadgets or anywhere in your program (but please note, if your program runs on the Workbench screen or any place that the user can adjust the pens for, you'll have to be prepared to remap your images to match the user's pen selection). With gadgets you have far more than GadTools to work with; you also have BOOPSI, which is a tremendously powerful addition to Intuition and an integral part of Release 2. On the other hand, don't go overboard. It's okay to be creative with your GUI, just keep good taste and the standards in mind while you do so. You may think you have an idea for a GUI that would be really attractive, but before you go ahead and implement it, ask yourself if its really consistent with other Amiga GUIs that you could consider to be exemplary. * Pet Peeves: These are some things I have noticed in a lot of Amiga software that I personally find really annoying, and would love to see an end to all of them: - Programs that save their data files in the S: directory. "S" stands for "script", this directory is mainly used for AmigaDOS script files, leave it alone. The Style Guide defines very clearly where data files should be placed. At the very least, please use PROGDIR:. - Programs that ASSUME you are using an 8x8 font. Properly written software should adjust to the user's screen font setting (which may not be proportional). If you're not prepared to do this, the least you can do is make certain that you have an 8x8 font, and ask for it if you don't. - It's very annoying when you can't choose the screen mode an application runs in. By default, programmes should open in the same mode as the Workbench screen, while allowing you to change into any of the Amiga's allowed screen modes (check the display database for this). - Please try to get as many defaults as you can from a user's preferences settings. The screen mode example above is just one. Instead of defaulting to Topaz 8, default to the user's screen font selection. The system preferences are there for you to make use of, so do so. - Don't make use of non-standard requesters such as those provided by the ReqTools library. User's can patch their system to use these if they want to, but your application should always be coded to use the standard system requesters. - Stay away from forcing users to make special "assigns". With Release 2 there is little need for this since it is a trivial matter to find out what directory your program resides in (use the special DOS assignment PROGDIR:). * About the Author: I am student studying computing and information science at the University of Guelph in Ontario Canada. I have owned an Amiga since 1988. My first major programming project on the Amiga was TransAmiga BBS, which I continue to develop. More recently, I have written a system for programmers called GadLayout that greatly simplifies the task of making gadgets adjust dynamically to user font and language preferences (VERY important in being Style Guide compliant). My main focus over the last 6 months has been in writing a text editor which I hope will serve as an example of what a style-guide compliant user interface should look like. As you will have probably already gathered, user interface issues are my main interest in computing. I am available for any consulting or design work if you need help with the GUI in software you are developing. If you wish to get in touch with me, any of the following are methods are at your disposable, and are listed in order of preference: InterNet E-Mail: cs1087@snowhite.cis.uoguelph.ca FidoNet Netmail: 1:247/192.0 IRC: Timmer @ #amiga FAX: (416)682-3501 Regular Mail: 128 Riverview Blvd. St. Catharines, Ont. L2T 3M2 CANADA If you want suggestions, critisisms or insults about a GUI, feel free to contact me. I'm eager to help if it means that we'll get better looking, more functional and more standard GUIs out there in the Amiga community.